home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Kirk's Comm Disc 1995 December
/
Kirk's Comm Disc - Version 2.iso
/
dos
/
fido
/
ftsc_all.z43
/
FSC-0027.TXT
< prev
next >
Wrap
Text File
|
1988-12-04
|
19KB
|
533 lines
FSC-0027
The Distribution Nodelist
by Ben Baker, 1:100/76
updated by Rick Moore, 1:115/333
December 4, 1988
Copyright 1986, 1987, 1988 International FidoNet Association. All
rights reserved. Duplication and or distribution permitted for
non-commercial purposes only.
This document is a proposed update for the document known under
the names of FSC002-4, FSC-0002, and FTS-0002.
This document defines the format and content of the nodelist for
the Public FidoNet Network (PFN) as published each Friday.
The PFN is an international network of independently owned
electronic mail systems, most with interlocking electronic
bulletin board systems. The distribution nodelist, or simply
"nodelist," is the glue which holds the network together. It is
the PFN's "phone book" and it defines the top-level network
structure.
The nodelist is published as an ASCII text file named
NODELIST.nnn, where nnn is the day-of-year of the Friday
publication date. This file is packed into an archive file (by
System Enhancement Associates' ARC utility) named NODELIST.Ann,
where nn are the last two digits of day-of-year.
A companion file, COORD.nnn, lists the coordinators of the
various regions and local networks which constitute the PFN. This
file may be created from NODELIST.nnn by the program COORD.EXE,
distributed by many PFN bulletin boards.
As stated above, NODELIST.nnn is an ASCII text file. It contains
two kinds of lines, comment lines and data lines. Each line is
terminated with an ASCII carriage return and line feed character
sequence, and contains no trailing white-space (spaces, tabs,
etc.). The file is terminated with an end-of-file character (EOF
= decimal character value 26).
Comments lines contain a semicolon (;) in the first character
position followed by zero or more alphabetic characters called
"interest flags." A program which processes the nodelist may use
comment interest flags to determine the disposition of a comment
line. The remainder of a comment line (with one exception,
treated below) is free-form ASCII text. There are five interest
flags defined as follows:
;S This comment is of particular interest to Sysops.
;U This comment is of particular interest to BBS users.
Page 1
;F This comment should appear in any formatted "Fido List."
;A This comment is of general interest (shorthand for ;SUF).
;E This comment is an error message inserted by the nodelist
generating program MakeNL.
; This comment may be ignored by a nodelist processor.
The first line of a nodelist is a special comment line containing
identification data for the particular edition of the nodelist.
The following is an example of the first line of a nodelist:
;A FidoNet Nodelist for Friday, July 3, 1987 --
Day number 184 : 15943
This line contains the general interest flag, the day, date,
and day-of-year number of publication, and ends with a 5-digit
decimal number with leading zeros, if necessary. This number is
the decimal representation of a check value derived as follows:
Beginning with the first character of the second line, a
16-bit cyclic redundancy check (CRC) is calculated for the
entire file, including carriage return and line feed
characters, but not including the terminating EOF
character. The check polynomial used is the same one used
for many file transfer protocols:
2**16 + 2**12 + 2**5 + 2**0
The CRC may be used to verify that the file has not been edited.
The importance of this will become evident in the discussion of
NODEDIFF, below. CRC calculation techniques are well documented
in the literature, and will not be treated further here.
The content of the remaining comments in the nodelist are
intended to be informative. Beyond the use of interest flags for
distribution, a processing program need not have any interest in
them.
A nodelist data line contains eight variable length "fields"
separated by commas (,). No space characters are allowed in a
data line, and underscore characters are used in lieu of spaces.
The following discussion defines the contents of each field in a
data line.
Field 1: Keyword
The keyword field may be empty, or may contain one of the
following:
Zone --
Begins the definition of a geographic zone and define
its coordinator. All the data lines following a line
with the "Zone" keyword down to, but not including the
Page 2
next occurrence of a "Zone" keyword, are regions,
nets and nodes within the defined zone.
Region --
Begins the definition of a geographic region and
defines its coordinator. All the data lines following
a line with the "Region" keyword down to, but not
including the next occurrence of a "Region" or "Host"
keyword, are independent nodes within the defined
region.
Host --
Begins the definition of a local network and defines
its host. All the data lines following a line with the
"Host" keyword down to, but not including the next
occurrence of a "Region" or "Host" keyword, are local
nodes, members of the defined local network. The
difference between a region and a local network is in
the routing of messages. A message addressed to a
member of a region is sent direct to the addressee,
while a message to a member of a local network is sent
to the network host.
Hub --
Begins the definition of a routing subunit within a
multilevel local network. The hub is the routing
focal point for nodes listed below it until the next
occurrence of a "Hub", "Region", "Host", or "Zone"
keyword. The hub entry MUST be a redundant entry,
with a unique number, for one of the nodes listed
below it. This is necessary because some nodelist
processors eliminate these entries in all but the local
network.
Pvt --
Defines a private node with unlisted number. Private
nodes are only allowed as members of local networks.
Hold --
Defines a node which is temporarily down. Mail may
be sent to it and is held by its host or coordinator.
Down --
Defines a node which is not operational. Mail may NOT
be sent to it. This keyword may not be used for
longer than two weeks on any single node, at which
point the "down" node is to be removed from the
nodelist.
<empty> --
Defines a normal node entry.
Field 2 - Net/Node number
Page 3
This field contains only numeric digits and is a number in
the range of 0 to 32767. If the line had the "Zone",
"Region", or "Host" keyword, the number is the zone,
net, or region number, and the node has an implied node
number of 0. Otherwise, the number is the node number.
The zone number, region or net number, and the node
number, taken together, constitutes a node's FidoNet
address.
Zone numbers must be unique. Region or net numbers must be
unique within their zone. Other numbers must be unique
within their respective units.
Field 3 - Node name
This field may contain any characters except commas and
spaces. Underscores are used to represent spaces. This is
the name by which the node is known.
Field 4 - Location
This field may contain any characters except commas and
spaces. Underscores are used to represent spaces. This
field contains the location of the node. In the USA it is
typically "City_ST where ST is the standard two-letter
abbreviation for the state.
Field 5 - Sysop name
This field may contain any characters except commas and
spaces. Underscores are used to represent spaces. This is
the name of the system operator.
Field 6 - Phone number
This field contains at least three and usually four numeric
subfields separated by dashes (-). The fields are country
code (1 for USA and Canada), city or area code, exchange
code, and number. The various parts of the phone number
are frequently used to derive cost and routing information,
as well as what number is to be dialed. A typical example
of the data in a phone number field is 1-800-555-1212,
corresponding to country 1 (USA), area 800 (inward WATS),
exchange 555, and number 1212.
Alternatively, this field may contain the notation
"-Unpublished-" in the case of a private node. In this
case, the keyword "Pvt" must appear on the line.
Field 7 - Baud rate
This field contains one of the values: 300, 1200, 2400,
or 9600, and defines the maximum baud rate supported by the
node.
Field 8 - Flags
Page 4
This optional field contains data about the specific
operation of the node, such as file requests, modem
protocol supported, etc. Any text following the sixth
comma on a data line is taken collectively to be the flags
field. The required format is zero or more subfields,
separated by commas, consisting of a flag, possibly
followed by a value.
The following flags define special operating conditions:
Flag Meaning
CM Node accepts mail 24 hours a day
MO Node does not accept human callers
The following flags define modem protocols supported:
Flag Meaning
CT1 CCITT V21 300 bps
CT2 CCITT V23 1200/75 split bps rate
CT3 CCITT V22 1200 bps full duplex
HAY Hayes V9600
HST USR Courier HST
MAX Microcom AX/96xx series
PEP Telebit TrailBlazer
V32 CCITT V32
V33 CCITT V33
V34 CCITT V34
NOTE: Many V22 modems also support Bell 212A.
If no modem flag is given, Bell 212A is assumed for
1200 bps systems, CCITT V22bis is assumed for 2400 bps
systems.
The following flags define type of error correction
available. A separate error correction flag should not be
used when the error correction type can be determined by the
modem flag. For instance, a modem flag of HST implies MNP.
Flag Meaning
MNP Microcom Networking Protocol error correction
V42 LAP-M error correction w/fallback to MNP
The following flags define the type(s) of compression of
mail packets supported.
Flag Meaning
Page 5
MN No compression supported
NOTE: The only compression method supported
by FidoNet at this time is SEA's ARC, as
defined by the specs for ARCMail 0.6. When
other types of mail compression are adopted,
indicators for them will be added. For now,
the absence of a compression flag indicates
that ARCMail 0.6 compression is supported.
The following flags indicate the types of file/update
requests supported.
Flag Meaning
XA Bark and WaZOO file/update requests
XB Bark file/update requests, WaZOO file
requests
XP Bark file/update requests
XR Bark and WaZOO file requests
XW WaZOO file requests
The following flag defines gateways to other domains
(networks).
Flag Meaning
Gx Gateway to domain 'x' where 'x` is a value
from 'A' to 'Z` or `1' to '9'.
NOTE: Valid values of 'x' are assigned by
the FidoNet International Coordinator.
Current valid values of 'x' may be found in
the notes at the end of the current FidoNet
nodelist.
The following flags define the dedicated mail periods
supported. They have the form "#nn" or !nn where nn is the
UTC hour the mail period begins, # indicates Bell 212A
compatibility and ! indicates incompatibility with Bell
212A.
Flag Meaning
#02 Zone 2 mail hour (02:30 - 03:30 UTC)
#09 Zone 1 mail hour (09:00 - 10:00 UTC)
#18 Zone 3 mail hour (18:00 - 19:00 UTC)
NOTE: When applicable, the mail period
flags may be strung together with no
intervening commas, eg. "#02#09". Only
mail hours other than that standard within a
node's zone should be given. Since
Page 6
observance of mail hour within one's zone is
mandatory, it should not be indicated.
The following flag defines user-specific values. If
present, this flag MUST be the last flag present in a
nodelist entry.
Flag Meaning
Ux..x A user-specified string, which may contain
any character except blanks. This string may
contain one to thirty-two characters of
information that may be used to add
user-defined data to a specific nodelist
entry. This string may not contain any flags
already defined in this document. FTSC makes
no guarantee that it will not assign an
unused letter/number to new flags. Certain
unused flags are already reserved - see the
list below.
The following flags are reserved for future planned
expansion of existing flags: Mx and Px (where 'x' is any
valid character). This is not meant to imply that FTSC will
not use any to use any other character sequences, and FTSC
reserves the right to assign any flag deemed necessary.
The FTSC recognizes that the FidoNet International
Coordinator is the ultimate authority over what appears in
the FidoNet nodelist. Also, the FTSC is by definition a
deliberative body, and adding or changing a flag may take a
considerable amount of time. Therefore, the FidoNet
International Coordinator may temporarily make changes or
additions to the flags as defined in this document. The
FidoNet International Coordinator will then consult with
the FTSC over the changes needed to this document to reflect
these temporary changes.
The following are examples of nodelist data lines:
Host,102,SOCALNET,Los_Angeles_CA,John_Doe,1-213-874-9484,2400,XP
,101,Rainbow_Data,Culver_City_CA,Don_Brauns,1-213-204-2996,2400,
With more than a thousand nodes, the nodelist, even in archive
form, is a substantial document (or file). Since distribution
is via electronic file transfer, this file is NOT routinely
distributed. Instead, when a new nodelist is prepared, it is
compared with the previous week's nodelist, and a file
containing only the differences is created and distributed.
Page 7
The distribution file, called NODEDIFF.nnn, where nnn is the
day-of-year of publication, is actually an editing script which
will transform the previous week's nodelist into the current
nodelist. A definition of its format follows:
The first line of NODEDIFF.nnn is an exact copy of the first line
of LAST WEEK'S nodelist. This is used as a first-level
confidence check to insure that the right file is being edited.
The second and subsequent lines are editing commands and editing
data.
There are three editing commands and all have the same format:
<command><number>
<command> is a 1-letter command; A, C, or D. <number> is
a decimal number greater than zero, and defines the number
of lines to be operated on by the command. Each command
appears on a line by itself. The commands have the
following meanings:
Ann - Add the following nn lines to the output file.
Cnn - Copy nn unchanged lines from the input to the output
file.
Dnn - Delete (or skip) nn lines from the input file.
The following illustrate how the first few lines of NODEDIFF.213
might look:
;A Friday, July 25, 1986 -- Day number 206 : 27712
D2
A2
;A Friday, August 1, 1986 -- Day number 213 : 05060
;A
C5
This fragment illustrates all three editing commands. The first
line is the first line from NODELIST.206. The next line says
"delete the first two lines" from NODELIST.206. These are the
identification line and the line following it. The next command
says "add the next two lines" to NODELIST.213. The two data
lines are followed by a command which says "copy five unchanged
lines" from NODELIST.206 to NODELIST.213. Notice that the first
line added will ALWAYS contain the new nodelist's CRC.
Since only the differences will be distributed, it is important
to insure the accuracy of the newly created nodelist. This is
the function of the CRC mentioned above. It is sufficient for a
program designed to perform the above edits to pick the CRC
value from the first line added to the output file, then compute
the CRC of the rest of the output file. If the two CRCs do not
agree, one of the input files has been corrupted. If they do
agree, the probability is very high (but not 100%) that the
output file is accurate.
Page 8
For actual distribution, NODEDIFF.nnn is packed into an archive
file named NODEDIFF.Ann, where nn are the last two digits of
day-of-year.
Page 9